[raster] ST_Clip should not impose a nodata value when the source raster do not have one

[pracine]

In the case where:

1) the input raster do not have a nodata value defined

2) no alternative nodata values are provided

The behavior right now is to set a nodata value to the resulting raster using ST_MinPossibleValue(ST_BandPixelType(rast)). We should not do that…

Most users would expect to get a raster with no nodata value defined since this is what they provided. However in the case the geometry is not a rectangle aligned with the raster (e.g a circle), there must be a way to set some pixels to nodata.

When the provided raster have a nodata defined, this nodata value is used. No problem.

When an array of nodata value is provided, those nodata values are used. No problem.

There is no such need in the case where the geometry is a rectangular fraction of the raster extent or when the geometry encompasses the raster and hence there is no need to set a nodata value in the resulting raster but we have no way to know that.

When both of those conditions are not met (the provided raster do not have a nodata defined AND no array of nodata value is provided) and hence absolutely no nodata value is known, instead of imposing ST_MinPossibleValue() we should just NOTICE the user that we could not set a nodata value and that if he wants one to be defined he must use one of the variant accepting nodata values (or set a nodata value to its raster before clipping).

[pracine]

Note that this is not the case for ST_Intersection(raster, raster) since in this case we produce a new raster and we do not expect the resulting raster to have exact same characteristics as the input rasters. This is the case for ST_Clip: the user expect to get a raster similar to the one provided except for its extent (including nodata areas).

[dustymugs]

Fixed in -trunk (2.1) as of r10568.

[dustymugs]

Fixed in 2.0 as of r10570